home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group02b.txt / 000034_icon-group-sender_Tue Sep 17 08:33:24 2002.msg < prev    next >
Internet Message Format  |  2003-01-02  |  4KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.11.1/8.11.1) id g8HFXAk06288
  4.     for icon-group-addresses; Tue, 17 Sep 2002 08:33:10 -0700 (MST)
  5. Message-Id: <200209171533.g8HFXAk06288@baskerville.CS.Arizona.EDU>
  6. From: Christopher Browne <cbbrowne@acm.org>
  7. X-Newsgroups: comp.lang.icon
  8. Subject: Re: Icon Wish 2
  9. Date: 17 Sep 2002 14:42:23 GMT
  10. X-Draft-From: ("nnvirtual:Languages" 943)
  11. X-Home-Page: http://www.cbbrowne.com/info/
  12. X-Emacs-Acronym: Emacs May Alienate Clients and Supporters
  13. Microsoft: Making the world a better place... for Microsoft.
  14. X-Uboat-Death-Message: ATOMIC BOMB. ATTACKED. LEAVE BOAT. U-811.
  15. To: icon-group@cs.arizona.edu
  16. Errors-To: icon-group-errors@cs.arizona.edu
  17. Status: RO
  18.  
  19. The world rejoiced as TrolletAtskynetDOTbe <complaint@nospam.org> wrote:
  20. > Christopher Browne wrote:
  21. >> There seem to be two other implementations of the ".NET VM," which
  22. >> /could/ be a counterargument.  But I doubt they will be /realistic/
  23. >> alternatives to .NET anymore than the "UNIX port" of DCOM made it
  24. >> realistic to deploy COM-based applications on UNIX.
  25. >
  26. > I put a :-) after my question 'What is .NET' - but I was serious when I
  27. > wrote it.
  28. > Let me think .. when did I first hear of it? Two years back?
  29. > When did I last hear of it? Two years back.
  30. > So it has become an integral part of Windows development after all?
  31. > As long as it doesn't infect non-Windows areas, I guess that is OK.
  32.  
  33. I'm not sure it's "integral" yet.  (I suspect it has too many
  34. discontinuities to be piece-wise continuous, and thus integrable...
  35. :-))
  36.  
  37. > Everybody seemed to agree that a framework like .NET was a Good Thing
  38. > (tm) but they also suspected that Microsoft would certainly find a way
  39. > to take a Good Thing and do something bad with it ... so they did, it
  40. > seems.
  41. > Two years back, I wanted to find out what it was ... now I am more
  42. > relaxed about it.
  43.  
  44. There still seems to be a lot of "vaporware" about it.  Be sure to
  45. realize that it's competition to J2EE, as opposed to other things.
  46.  
  47. >> It would seem to me to make a /lot/ more sense to try to deploy Icon
  48. >> atop the upcoming Perl "Parrot" bytecode system.  Consider that:
  49. >>  a) It /is/ intended to be portable;
  50. >>  b) There is intent for it to be not /totally/ Perl-oriented, as the
  51. >>     Python and Ruby communities have had discussions about cooperation;
  52. >>  c) It is not inconceivable that you could submit changes to Parrot to
  53. >>     the Perl team, and have /some/ hope of them being accepted.
  54. >
  55. > If Icon can find its way in between Perl and C somewhere ... I guess it
  56. > might benefit from taking advantage of a Perl source-to-bytecode
  57. > compiler/bytecode runtime in one end and icont in the other?
  58. >
  59. > Of course, if a bytecode-to-binary compiler is made, then icont is not
  60. > needed ... and Perl becomes a compiled language, too.
  61. >
  62. > Good idea?
  63.  
  64. Actually, I don't think so.  Generating native code has at least two
  65. demerits here:
  66.  
  67.  a) Compiled code is no longer portable across platforms;
  68.  b) Native-compiled code tends to be a LOT bigger than bytecode (by
  69.     around a factor of five, for cases I've seen), and this doesn't
  70.     necessarily lead to greatly improved performance.
  71.  
  72. The code that gets helped by "native compilation" is tight loops
  73. involving primitive operations.  For Perl, and Icon, for that matter,
  74. code that is /interesting/ will make extensive use of string pattern
  75. matching (regexes, in Perl), and that sort of code will dig into the
  76. "native-compile" libraries, and perform well even with 'byte-compiled'
  77. code.
  78.  
  79. Perl code that's doing tight loops
  80.  foreach $i (0..7500) {
  81.    $FOO{$i} += $BAR[$i];
  82.  }
  83. /might/ be helped by native compilation, although the fact that the
  84. objects are rather dynamic may mean that this particular code snippet
  85. wouldn't be helped at all.
  86.  
  87. Perl code that does extensive regex work generally /isn't/ slower than
  88. the equivalent C code, because in both cases, the code that gets run a
  89. lot is the heavily-optimized regular expression libraries.
  90. -- 
  91. (reverse (concatenate 'string "gro.mca@" "enworbbc"))
  92. http://cbbrowne.com/info/languages.html
  93. "The only completely consistent people are the dead."
  94. -- Aldous Huxley
  95.